[セッションレポート] Designing for SaaS #reinvent

[セッションレポート] Designing for SaaS #reinvent

Clock Icon2014.11.17

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

この記事は AWS re:Invent 2014のARC304 - Designing for SaaS: Next-Generation Software Delivery Models on AWSのレポートです。

レポート

次世代のSaaS設計に関する内容です。

DSC_1965

なぜSaaSか?

  • SaaSの採用が急速に伸びている
  • SaaSが可能な物
  • 新市場にリーチ
  • 既に存在しているものを基に成長する
  • 既存企業を崩壊させる
  • 新プロダクトのリリースと採用が加速している

DSC_1971

SaaSソリューション設計のベストプラクティス

  • プログラムからプラットフォームを分ける
  • 抽象化を通じた将来性
  • マルチ-マルチ-テナントのための設計
  • あなたのデータのライフサイクルを知る
  • 全てを集めて、そこから学ぶ
  • コストと性能の最適化
  • 安全と隔離

データライフサイクル管理の例

時間軸によってデータを変換、集計/集約を行い、データストアを入れ替える事により、アクセス速度をやコストを最適化します。 例えば、数分単位の場合は、Kinesisで受けて集計しS3へ保存したり、RDSで保存をします。 数時間の場合は、EMR等で処理をしDynamoDBへ保存します。 数日単位の場合は、Redshiftへ保存します。 数週間単位の場合は、RedshiftのデータをEMR等でさらに処理し、Redshiftへ保存します。 数ヶ月単位の場合は、S3へ保存します。 年単位の場合は、Glacierへアーカイブします。

DSC_1986

SaaSコンポーネント・アーキテクチャ - 監視

Kinesis、S3、DynamoDB、RDS(RDSはまだ対応していないですね)等のアプリケーションデータをLambdaで処理しSQSへ登録したり、アプリケーションの行動をSQSへ登録します。キューの内容処理して監視や分析の機能へ渡します。

DSC_1991

SaaSコンポーネント- 分析

アプリデータ、計測データ、課金データをData PipelineでS3で変換しS3へ保存します。S3のデータをそのままRedshiftへ保存したり、EMRで集約や分析してRedshidtやS3へ保存します。ユーザは、レポートやクエリでデータを参照します。

DSC_1994

SaaS on AWS:アーキテクチャ上のアプローチ

  1. 隔離された顧客のスタック 顧客毎に独立したAWSリソース DSC_1999
  2. 純粋なSaaSの共有アーキテクチャ 上から下まで共有インフラストラクチャでのオンデマンドリソース利用 DSC_2002
  3. 共有プラットフォーム上のコンテナ化 Amazon EC2 Container Service(ECS)とDockerでAWSの薄片を提供する DSC_2006

SaaS on AWSによりあなたの顧客に集中できる

  • AWSの柔軟性 → 費用効果の高い方法でアプリケーションのニーズに素早く対応する
  • AWSのイノベーション → 全てを自分で構築する事無く最新の業界動向に追いつく
  • AWSのエコシステム → AWSプラットフォームで巨人の肩に立つ

DSC_2014

まとめ

Designing for SaaSは自分が聞いた中で、一番勉強になったセッションです。 発表されたばかりのLambdaやECSを自然に使用しているアーキテクチャを例示しており、新サービスの利用例としても非常に勉強になりました。データライフサイクルの階層化や、システムのインフラ集約の参考に丁度良いセッションでした。 SaaSを主題としていますが、企業内システムでも同様のアーキテクチャを考えて行く必要があると思います。システム毎のITインフラを構築せずに、本セッションの様な全体のインフラ基盤を構築して、ビジネスを加速させましょう。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.